the parachute boards were sending multiple acknowledgment messages. the
sender would reset the acknowledgment atomic to false, but then
immediately set it back to true. We also use a signal instead of a watch
for the motor i_sense hoping to avoid it immediately returning
read_until_pos due to stale values in the watch.

rather than call .unwrap() on things, I have gone through and tried to
propagate errors and handle them instead. When unwrap or expect is the
simplest option, I've replaced them with defmt's unwrap instead of the
builtin as it should use less resources.

I was checking the wrong time for whether or not to send the heartbeat
message. Changed to time_now and it fixed the error

high means shorepower is off, low means it's on

this is maybe not a "bug" but it is a safety concern. we should never be
unlocking th rings when shorepower is on. this prevents that.

we don't need to recreate the ring pos receiver every time we run the
motor. this is a minor optimization but anything to keep the motor
running operation as lean as possible is a good thing in my opinion.

this may or may not be necessary but since running the motor will wait
for this task, doing it more often seems smart

Fix two errors where rocket ready was assumed to be active high, but
it's actually active low. This was being masked by another error where
rocket ready was being asserted when shorepower was on.

forgot to make buzz_mode mut, linter didnt care because it doesnt use
cfgs so it never thought it was being changed. also suppress some lints
that occur because of cfg directives. Tested and working as normal on
sender board

We should ignore the 100us continuity check the stratologger does when
powering off. Also, panicing when there's an error sending the can
deploy message is not a good idea, for now just log the error and keep
going.

Mostly just syntax errors, but I will need to figure out how to not
panic inside the error handler when making the strings for the limits
command

When the CAN bus is down, if the telemetrum fires it will hold on to the
shore power pin mutex until it can send a can message. The main thread
will wait until it can unlock this mutex before it does anything else so
that it can update state. this means if the CAN bus can't send the
deploy message, nothing else can happen.